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On the Use of Stream Control Transmission Protocol (SCTP) with IPsec 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


This document describes functional requirements for IPsec (RFC 2401) 
and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in 
securing SCTP (RFC 2960) traffic. 


1. Introduction 


The Stream Control Transmission Protocol (SCTP) is a reliable 
transport protocol operating on top of a connection-less packet 
network such as IP. SCTP is designed to transport PSTN signaling 
messages over IP networks, but is capable of broader applications. 


When SCTP is used over IP networks, it may utilize the IP security 
protocol suite [RFC2402] [RFC2406] for integrity and confidentiality. 
To dynamically establish IPsec Security Associations (SAs), a key 
negotiation protocol such as IKE [RFC2409] may be used. 


This document describes functional requirements for IPsec and IKE to 
facilitate their use in securing SCTP traffic. In particular, we 
discuss additional support in the form of a new ID type in IKE 
[RFC2409] and implementation choices in the IPsec processing to 
accommodate for the multiplicity of source and destination addresses 
associated with a single SCTP association. 
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1.1. Terminology 


In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 
described in [RFC-2119]. 


2. SCTP over IPsec 


When utilizing the Authentication Header [RFC2402] or Encapsulating 
Security Payload [RFC2406] protocols to provide security services for 
SCTP frames, the SCTP frame is treated as just another transport 
layer protocol on top of IP (same as TCP, UDP, etc.) 


IPsec implementations should already be able to use the SCTP 
transport protocol number as assigned by IANA as a selector in their 


Security Policy Database (SPD). It should be straightforward to 
extend existing implementations to use the SCTP source and 
destination port numbers as selectors in the SPD. Since the concept 


of a port, and its location in the transport header is 
protocol-specific, the IPsec code responsible for identifying the 
transport protocol ports has to be suitably modified. This, however 
is not enough to fully support the use of SCTP in conjunction with 
IPsec. 


Since SCTP can negotiate sets of source and destination addresses 
(not necessarily in the same subnet or address range) that may be 
used in the context of a single association, the SPD should be able 
to accommodate this. The straightforward, and expensive, way is to 
create one SPD entry for each pair of source/destination addresses 
negotiated. A better approach is to associate sets of addresses with 
the source and destination selectors in each SPD entry (in the case 
of non-SCTP traffic, these sets would contain only one element). 
While this is an implementation decision, implementors are encouraged 
to follow this or a similar approach when designing or modifying the 
SPD to accommodate SCTP-specific selectors. 


Similarly, SAs may have multiple associated source and destination 
addresses. Thus an SA is identified by the extended triplet ({set of 
destination addresses}, SPI, Security Protocol). A lookup in the 
Security Association Database (SADB) using the triplet (Destination 
Address, SPI, Security Protocol), where Destination Address is any of 
the negotiated peer addresses, MUST return the same SA. 
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3- 


SCTP and IKE 


There are two issues relevant to the use of IKE when negotiating 
protection for SCTP traffic: 


a) Since SCTP allows for multiple source and destination network 
addresses associated with an SCTP association, it MUST be possible 
for IKE to efficiently negotiate these in the Phase 2 (Quick Mode) 
exchange. The straightforward approach is to negotiate one pair of 
IPsec SAs for each combination of source and destination addresses. 
This can result in an unnecessarily large number of SAs, thus wasting 
time (in negotiating these) and memory. All current implementations 
of IKE support this functionality. However, a method for specifying 
multiple selectors in Phase 2 is desirable for efficiency purposes. 
Conformance with this document requires that implementations adhere 
to the guidelines in the rest of this section. 


Define a new type of ID, ID_LIST, that allows for recursive inclusion 
of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP association 
MAY be of type ID_LIST, which would in turn contain as many 
ID_IPV4_ADDR IDs as necessary to describe Initiator addresses; 
likewise for Responder IDs. Note that other selector types MAY be 
used when establishing SAs for use with SCTP, if there is no need to 
use negotiate multiple addresses for each SCTP endpoint (i.e., if 
only one address is used by each peer of an SCTP flow). 
Implementations MUST support this new ID type. 


ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the ID 
types defined in [RFC2407] can be included inside an ID_LIST ID. 
Each of the IDs contained in the ID_LIST ID must include a complete 
Identification Payload header. 


The following diagram illustrates the content of an ID_LIST ID 
payload that contains two ID_FQDN payloads. 
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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! ID Type ! Protocol ID ! Port ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! ID Type ! Protocol ID ! Port ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
~ FQDN 1 Identification Data < 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! 


Next Payload ! RESERVED ! Payload Length ! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
! ID Type ! Protocol ID ! Port ! 


+-+-4+-4+-+-+4+-4+-4+-+-4-4+-+4-4+-4+-4+-4+-4-4+-4+-4+-4+-+-+4+-4-4+-4+-4-4+-4-4+-4+-4-4+ 
a FQDN 2 Identification Data a 
+-+-4+-4+-+-+4+-4+-+-+-4+-4+-+-4-4+-+-+-4-4+-+4-4-4+-4+-4+-4-4+-4+-4-4+-4-4+-4-4-4+ 


The Next Payload field in any of the included IDs (for FQDN 1 and 
FQDN 2) MUST be ignored by the Responder. The Payload Length, ID 
Type, Protocol ID, and Port fields of the included Payloads should be 
set to the appropriate values. The Protocol ID and Port fields of 
the ID_LIST Payload should be set to zero by the Initiator and MUST 
be ignored by the Responder. 


Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be 
included inside the same ID_LIST ID. If an ID type included in an 
ID_LIST ID payload is invalid in the context the ID_LIST ID is used, 
the whole ID_LIST should be considered to be at fault, e.g., if an 
ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is 
received during an IKE Quick Mode exchange, the Responder should 
signal a fault to the Initiator and stop processing of the message 
(the same behavior it would exhibit if simply an ID_FOQDN was received 
instead). 


The IANA-assigned number for the ID_LIST ID is 12. 


b) For IKE to be able to validate the Phase 2 selectors, it must be 
possible to exchange sufficient information during Phase 1. 
Currently, IKE can directly accommodate the simple case of two peers 
talking to each other, by using Phase 1 IDS corresponding to their IP 
addresses, and encoding those same addresses in the SubjAltName of 
the certificates used to authenticate the Phase 1 exchange. For more 
complicated scenarios, external policy (or some other mechanism) 
needs to be consulted, to validate the Phase 2 selectors and SA 
parameters. All addresses presented in Phase 2 selectors MUST be 
validated. That is, enough evidence must be presented to the 
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Responder that the Initiator is authorized to receive traffic for all 
addresses that appear in the Phase 2 selectors. This evidence can be 
derived from the certificates exchanged during Phase 1 (if possible); 
otherwise it must be acquired through out-of-band means (e.g., policy 
mechanism, configured by the administrator, etc.). 


In order to accommodate the same simple scenario in the context of 
multiple source/destination addresses in an SCTP association, it MUST 
be possible to: 


1) Specify multiple Phase 1 IDs, which are used to validate Phase 
2 parameters (in particular, the Phase 2 selectors). Following 
the discussion on an ID_LIST ID type, it is possible to use the 
same method for specifying multiple Phase 1 IDs. 


2) Authenticate the various Phase 1 IDs. Using pre-shared key 
authentication, this is possible by associating the same shared 
key with all acceptable peer Phase 1 IDs. In the case of 
certificates, we have two alternatives: 


a) The same certificate can contain multiple IDs encoded in 
the SubjAltName field, as an ASN.1 sequence. Since this is 
already possible, it is the preferred solution and any 
conformant implementations MUST support this. 


b) Multiple certificates MAY be passed during the Phase 1 
exchange, in multiple CERT payloads. This feature is also 
supported by the current specification. Since only one 
signature may be issued per IKE Phase 1 exchange, it is 
necessary for all certificates to contain the same key as 
their Subject. However, this approach does not offer any 
significant advantage over (a), thus implementations MAY 
support it. 


In either case, an IKE implementation needs to verify the 
validity of a peer’s claimed Phase 1 ID, for all such IDs 
received over an exchange. 


Although SCTP does not currently support modification of the 
addresses associated with an SCTP association (while the latter is in 
use), it is a feature that may be supported in the future. Unless 
the set of addresses changes extremely often, it is sufficient to do 
a full Phase 1 and Phase 2 exchange to establish the appropriate 
selectors and SAs. 
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The last issue with respect to SCTP and IKE pertains to the initial 
offer of Phase 2 selectors (IDs) by the Initiator. Per the current 
IKE specification, the Responder must send in the second message of 
the Quick Mode the IDs received in the first message. Thus, it is 

assumed that the Initiator already knows all the Selectors relevant 
to this SCTP association. In most cases however, the Responder has 
more accurate knowledge of its various addresses. Thus, the IPsec 

Selectors established can be potentially insufficient or inaccurate. 


If the proposed set of Selectors is not accurate from the Responder’s 
point of view, the latter can start a new Quick Mode exchange. In 
this new Quick Mode exchange, the roles of Initiator and Responder 
have been reversed; the new Initiator MUST copy the SA and Selectors 
from the old Quick Mode message, and modify its set of Selectors to 
match reality. All SCTP-supporting IKE implementations MUST be able 
to do this. 


4. Security Considerations 


This documents discusses the use of a security protocol (IPsec) in 
the context of a new transport protocol (SCTP). SCTP, with its 
provision for mobility, opens up the possibility for 
traffic-redirection attacks whereby an attacker X claims that his 
address should be added to an SCTP session between peers A and B, and 
be used for further communications. In this manner, traffic between 
A and B can be seen by X. If X is not in the communication path 
between A and B, SCTP offers him new attack capabilities. Thus, all 
such address updates of SCTP sessions should be authenticated. Since 
IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate 
all addresses attached to an SCTP endpoint either through validating 
the certificates presented to it during the Phase 1 exchange, or 
through some out-of-band method. 


The Responder in a Phase 2 exchange MUST verify the Initiator’s 
authority to receive traffic for all addresses that appear in the 
Initiator’s Phase 2 selectors. Not doing so would allow for any 
valid peer of the Responder (i.e., anyone who can successfully 
establish a Phase 1 SA with the Responder) to see any other valid 
peer’s traffic by claiming their address. 


5. IANA Considerations 
IANA has assigned number 12 for ID_LIST (defined in Section 3) in the 


"IPSEC Identification Type" registry from the Internet Security 
Association and Key Management Protocol (ISAKMP) Identifiers table. 
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6. Intellectual Property Rights Notice 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assignees. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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